Object identity and equality are important concepts in computer programming. Every programming language must provide some method for determining the identity of an object and for determining whether two objects are equal.
In relational databases, object identity is encoded via the notion of primary keys. Two rows are considered the same if their primary keys are equal. This assumes, of course, that recursively that question can be answered.
In contrast, in imperative and object-oriented languages, object instances are ultimately identified by their address in memory, which represents their “identity.” For example, in the following segment of Visual Basic code, both variables X and Y refer to the same object in memory and therefore have the same “reference identity” (in Visual Basic, a test for reference identity may be performed using “Is”):                Dim X=New Person With {.Name=“Paul”}        Dim Y=X        Assert(X Is Y)        Y.Name=“Amanda”        Assert(X.Name=“Amanda”)Because X and Y have the same reference identity, a change to the Name property via variable Y is visible when accessing the Name property via variable X.        
In many situations, it is useful to provide a second notion of equality for objects that is based on the value of objects as opposed to their location in memory. For instance, the variable P and Q below point to two different Person instances:                Dim P=New Person With {.Name=“Tim”}        Dim Q=New Person With {.Name=“Tim”}        Assert(P=Q)        Assert(P IsNot Q)However, a software developer may wish to consider two Person instances to be the same whenever the .Name properties associated with those instances are the same, so in this case, the programmer may want to assert that P is the same as Q using the =operator.        
In some programming languages, programmers can redefine equality on their objects. For example, Microsoft® .NET™ programming languages allow programmers to redefine equality on their objects by overriding the following two virtual methods on the Object class which is at the root of the type hierarchy:
Public Overridable Function Equals (obj As Object) As Boolean
Public Overridable Function GetHashCode( ) As Integer
Other languages/runtimes provide similar protocols. The standard contract in the .NET framework for the Equals and GetHashCode functions is that they satisfy the following rather intricate properties:
(1) x.Equals(x) returns true, except in cases that involve floating-point types;
(2) x.Equals(y) returns the same value as y.Equals(x);
(3) x.Equals(y) returns true if both x and y are NaN;
(4) (x.Equals(y) && y.Equals(z)) returns true if and only if x.Equals(z) returns true;
(5) Successive calls to x.Equals(y) return the same value as long as the objects referenced by x and y are not modified;
(6) x.Equals(a null reference (Nothing in Visual Basic)) returns false;
(7) If two objects compare as equal, the GetHashCode method for each object must return the same value. However, if two objects do not compare as equal, the GetHashCode methods for the two object do not have to return different values;
(8) The GetHashCode method for an object must consistently return the same hash code as long as there is no modification to the object state that determines the return value of the object's Equals method. Note that this is true only for the current execution of an application, and that a different hash code can be returned if the application is run again. For the best performance, a hash function must generate a random distribution for all input.
However, overriding Equals and GetHashCode in this manner is not always possible, typically involves incorporating a substantial amount of boiler plate code, and provides ample opportunity for introducing bugs. Furthermore, programming languages that utilize such object contracts do not typically provide any method of collapsing the notions of equality and identity outside of modifying the execution engine itself.